Hi All, I have a domain called comainA where exchange 2010 is installed. I have another domain called domainB where there is all users accounts. As the migration procedure I did the this: 1. I use Prepare-moverequest to migrate users account domainB to domainA as DISABLED MAILBOX ACCOUNT 2. I run admt to migrate users accounts from domainB to domainA to patch SID history. I deployed linked mailboxes and that is working fine. However when I run this comand to share mailbox: Add-MailboxPermission -Identity user01-User DOMAINB\USERB -AccessRights FullAccess the result show Identity User AccessRights IsInherited Deny -------- ---- ------------ ----------- ---- domaina\users\... DOMAINA\USERB {FullAccess} False False As you can see it doesn`t appears DOMAINB\USERB that's why shared mailbo doesn't work. Any ideas? Regards. Regards. Jos Osorio.

Hi Fiona, I was searching about my issue and I found that i could be the ADMT. When I add permission to users from other forest it works when i didn't migrate it with ADMT. So, I think that there is one or more attributes that shouldn`t be migrated with ADMT. Regards. Jos Osorio.

Hi Jose, Can you share the method you used to add permission? I tried to involved a next level engineer and your information would help us research. THanks.Fiona

Hi Fiona, This is command line: Add-MailboxPermission -Identity user01-User DOMAINB\USERB -AccessRights FullAccess As I mentioned if the UserB was migrated with ADMT that doesn`t work. However, is so strange because with users who were no migrated with ADMT that works. Regards. Jos Osorio.

Hi Jose, Sorry for the confusion, I would like to know how did you migrate the user without ADMT? Thanks again.Fiona

Hi Fiona, I've just ran Preparemoverequest.ps1 against some users. That script create a disabled account on exchange forest and enabled as a Contact. For other users as i want to migrate SID history. I ran Preparemoverequest.ps1 and then run ADMT.Regards. Jos Osorio.

Hello Jose, Just to make sure we are on the same page, what you have noticed is, when users are migrated from one forest to another along with their SID history (I.e. using admt), and then the corresponding users mailbox was moved, you are unable to apply and manage mailbox permissions. It does seem to apply, but to a wrong user DomainA\USERB in your case This is because of the SIDHistory on the account. It restricts the ability to properly lookup the correct user account. I can explain why this happens, but could you please remove / delete the SIDHistory from the user account and check the behavior ?

Hi Sunesh, I thought that SID history was the root of that issue. However, if I remove SID history then users from other forest can`t log automatically with Outlook. Regards.Regards. Jos Osorio.

Hi Sunesh, I'm worry about that behavior. You mean that I should migrate account without SID history, right?. Doing that user from other forest can't log in (single sign on) automatically on Outlook. That's a huge issue.Regards. Jos Osorio.

SID... If you add a user in Domain\user format, it needs to look up the SID, which it probably can't do because it lacks permissions in the "other" forest... The user won't resolve. If you add a SID, there is no lookup. If you remove the SID history, and it fails, this absolutly is the issue. Whatever account you are using to modify the permissions needs the ability to resolve the SID in the *other forest. J

What permissions I need? what do you mean when you said "If you add a SID, there is no lookup"?Regards. Jos Osorio.

Hello Jose, As you indicated, the sidhistory seems to be the root of the issue. Cross forest migration related issues demand some testing (depending on tools utilized for migration) in the live environemnt. Please open a case with Microsoft PSS to expedite the solution.

This is the exact same issue I am facing. Did you get a solution from MS on this one? Basically I ADMT (with SID History) from my users in domain B to a new user in domain A. I then prepare-moverequest and move the mailbox. My users still login to their PC with their domain B account so I need to give that full access to the new migrated mailbox in domain A. I run the same script as above (Add-MailboxPermission -Identity user1@domaina.local -accessrights "fullaccess" -user domainb\user1). I would expect this to show DOMAINB\user1 as having full access to the 2010 mailbox, but it doesnt. It looks like it just adds DOMAINA\user1 again or tells me the ACL is already present. This however does not happen to every mailbox I am migrating but the majority of them. Very, very frustrating.  

Instead of running the add-mailboxpermission run Add-ADPermission -Identity "shared" -User AccountDomain\user -AccessRights fullaccess Then try to open the shared mailbox.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Hi LambyUK, I finally solved. It was a problema of SID History. When I removed it from all users I had migrated everything Works fine. In order to remove sid history I check this link http://blogs.technet.com/b/ashleymcglone/archive/2011/11/23/how-to-remove-sid-history-with-powershell.aspx I hope this helps to everybody.Regards. Jos Osorio.

Thanks for the reply Jose. My question now then is, what exactly will removing the SID history do to my users? At the same time as an exchange migration I am also working on a user cutover from domain B to domain A so the user signs in on the same domain as exchange. Now part of the process I have been asked to follow in ADMT is that the SID migration history must be migrated. This is for access to file shares and groups across domains I believe. So what will removing the SID history do to that user account? As mentioned further up this thread, it would stop people being able to automatically login to their mailboxes wouldnt it?

In a resource forest you dont need sid history since the account is not being used. If the user accounts have a security identifier (SID) history, you must turn off SID filtering between the account forest and the resource forest (otherwise, users will not be able to access their mailboxes). Two ways in which accounts acquire a SID history http://technet.microsoft.com/en-us/library/aa997312(v=exchg.65).aspxJames Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

In a resource forest you dont need sid history since the account is not being used. If the user accounts have a security identifier (SID) history, you must turn off SID filtering between the account forest and the resource forest (otherwise, users will not be able to access their mailboxes). Two ways in which accounts acquire a SID history http://technet.microsoft.com/en-us/library/aa997312(v=exchg.65).aspx James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com James, in our case we still need our migrated users to be able to seamlessly access file shares on the old domain etc. This was my understanding why the SID history needed to be migrated between the old and new object? But it appears when the SID history is in place, we have this issue with giving full mailbox access to the legacy domain user as exchange 2010 gets confused on who its actually giving access too!

That is correct but in a resource forest you're not using the migrated AD account. Are you doing a resource forest migration? One of your posts says you're logging into the source forest but your second posts says you're logging into the same domain as Exchange. If you're logging into the source forest than you're not using the migrated AD account so the migrated AD account doesn't need the sid history.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Ah ok I see where the confusion is coming from. Ok so we have 2 projects going on side by side. As well as a migration of exchange, we are also cutting over users from legacy domains into a new 2008 domain (where exchange is installed). This however is a long process for various reasons, so at this point we have 3,000 users already migrated over but still have 7,000 users left to go. So this means, we have a large amount of users who still are logging into the source forest, but then accessing the mailbox which is on the new domain. The 3,000 users who have been migrated obviously still need to access file servers etc which are still on the legacy domains hence the requirement for the SID history. So I guess in thinking about it, if I am doing a mail migration for users who still will login to the source forest, I should do the ADMT for them without SID history. But when I am dealing with users who are actually being cutover to login to the new forest then SID history is essential. Does that sound about right?

Ouch that is an unconventional migration. You have 7k users left, instead of moving just their mailbox you can't just move both the AD and mailbox at the same time? If I were you I would go down this route. If not you can try running add-adpermission instead of add-mailboxpermission I belive that will work as well. Add-ADPermission -Identity user1 -User AccountDomain\user1 -AccessRights fullaccess James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Agreed, very unconventional indeed! We dont have the option of doing an actual user cutover at the same time die to many restrictions. However, the mail migration needs to move ahead regardless of the user cutover project. This is why I am left with so many users still logging in to the source forest. I do use add-adpermission for granting the "send as" rights to the source mailbox, but every article I have read states that you need to run add-mailboxpermission for Full Access.

I assume this is the steps you need to be doing 1. Use ADMT (dont bring over sid history) 2. Prepare move request then move mailbox 3. Then run set-user -id <USER> - LinkedMasterAccount sourcedomain\user -LinkedDomainController dc.sourcedomain.local The users will still be logging into the source domain so don't need sid history now. Once you're ready to migrate the account to the new forest, run ADMT again and bring over sid history. Then you need to unlink the mailbox and set it to the account in the new forest that you just migrated.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

I assume this is the steps you need to be doing 1. Use ADMT (dont bring over sid history) 2. Prepare move request then move mailbox 3. Then run set-user -id <USER> - LinkedMasterAccount sourcedomain\user -LinkedDomainController dc.sourcedomain.local The users will still be logging into the source domain so don't need sid history now. Once you're ready to migrate the account to the new forest, run ADMT again and bring over sid history. Then you need to unlink the mailbox and set it to the account in the new forest that you just migrated.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

That makes a lot of sense James. However, to date I have not used the linkedmasteraccount in any of the 3000 mailboxes migrated so far. Can you give me a little background to what it does? Why I should use it in my scenario etc Thanks for everyones comments so far, its certainly helping me identify where I need to be looking!

Ok, so I am a little confused on this one now. I did the following.. 1) removed the SID history on my new domain mailbox user object. 2) I then run the set-user command to link the master account to the source user object. Running this command disabled the target user object as you have described above. The issue I now seem to face, is when I login to the PC as the source domain user and try and open the mailbox I am constantly challenged for the credentials of the new domain user account. I dont see how it will authenticate as the mailbox user account is disabled as a result of converting to a linked mailbox. I would have thought however that the fact I have just linked to my source domain user, I shouldnt have needed to enter credentials to open the mailbox as I have just linked the 2 accounts no?

That should not happen since you linked the mailbox to the source forest. Log into OWA for the new mailbox and test authenticating with the source account. For your previous users how were you linking the mailboxes with the source accounts?James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

That should not happen since you linked the mailbox to the source forest. Log into OWA for the new mailbox and test authenticating with the source account. For your previous users how were you linking the mailboxes with the source accounts? James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com It would appear I was entering the wrong credentials. I still thought I needed to access the new credentials of the disabled object into outlook, when in fact I needed to enter the source user credentials. This makes things even better for me!! Cause now I dont have to confuse users with extra sets of credentials just for email access. This thread has REALLY helped me understand the correct way to migrate in my scenario. Its just a shame I only discovered this 3,000 migrations into the overall project!